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1.  INTRODUCTION 


The  application  and  utility  of  finite  element  models  extends 
throughout  an  aircraft's  life  cycle  from  its  early  conception 
throughout  its  development,  test,  production,  and  operational 
deployment.  These  models  must  be  accessed  by  various  Air  Force 
organizations  in  order  to  address  a  variety  of  structural  design 
criteria  during  each  of  these  stages.  The  widespread  usage  of 
finite  element  models  by  numerous  organizations  which  perform 
analyses  on  a  wide  range  of  applications  has  facilitated  the 
aircraft  design  and  analysis  process  by  reducing  the  dependence 

t 

on  costly  and  time-consuming  hardware  test  procedures.  However, 
it  has  also  resulted  in  the  widespread  proliferation  of  finite 
element  models  such  that  they  are  difficult  to  manage  on  an 
organizational  scale. 

Among  the  key  organizational  issues  pertaining  to  the 
management  of  finite  element  models  are  the  access abi li ty  and 
transportability  of  these  models  among  the  various  groups, 
organizat ions,  and  functions  which  require  them.  These  issues 
are  complicated  by  differences  in  geographic  location,  computing 
machinery,  finite  element  modeling  and  analysis  software, 
analysis  requirements,  model  fidelity,  and  other  specific 
applications.  The  combination  of  these  factors  results  in 
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organizational  inefficiencies  which  include  duplication  of 
effort,  inappropriate  analyses,  miscommun icat ion,  and  increased 
costs  thrc'jghoiit  the  aircraft  life  cycle. 

In  an  effort  to  alleviate  the  organizational  problems 
associated  with  the  management  of  finite  element  models,  the  Air 
Force  Wright  Aeronautical  Laboratories  (AFWAL)  has  determined 
that  it  is  necessary  to  examine  the  feasibility  of  implementing  a 
database  of  finite  element  models  which  can  facilitate  the 
transportability  and  accessability  of  finite  element  data  among 
the  various  organizations  which  require  them.  This  database  can 
comprise  a  central  repository  for  finite  element  data  which  can 
be  made  available  throughout  the  Air  Force.  The  advantages  of 
the  database  approach  include  decreased  costs  over  the  aircraft 
life  cycle,  increased  engineering  efficiency  among  the  various 
organizations  which  use  finite  element  data,  better  communication 
among  these  organizations,  higher  quality  models  and  analysis 
results,  and  an  enhancement  of  competition  among  Air  Force 
contractor  organizations. 


The  objective  of  this  Phase  I  SBIR  program  was  to  assess  the 
feasibility  of  developing  and  implementing  a  centralized  database 
of  finite  element  models  for  the  supportability  of  aircraft 
structures,  which  can  be  accessed  by  various  organizations 
throughout  the  Air  Force.  In  support  of  this  objective,  Astron 
Research  and  Engineering  has  studied  the  applications  of  finite 
element  modeling  and  analysis  throughout  the  aircraft  life  cycle. 
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including  various  organizations  within  the  Air  Force  who  use 
finite  element  data  during  these  life  cycle  stages.  These 
studies  were  then  used  to  df^vlse  functional  requirements  for  a 
centralized  database  of  finite  element  models,  and  implementation 
objectives  for  use  of  this  database  throughout  the  Air  Force.  The 
results  of  these  studies  are  discussed  below. 
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APPLICATIONS  OF  FINITE  ELEMENT  MODELS  IN  THE  AIR  FORCE 


A  brief  review  of  finite  element  model  usage  over  the  life 
cycle  of  an  aircraft  is  given  to  demonstrate  the  wide  application 
of  these  models,  and  the  need  to  retain,  access,  and  transport 
finite  element  data  among  the  organizations  which  need  them. 
This  review  is  v.cz2zs^t y  in  order  to  develop  requirements  for  the 
centralized  database  so  that  it  properly  addresses  the  technical 
needs  of  the  user  community  during  each  stage  of  the  aircraft 
life  cycle.  For  the  purposes  of  this  discussion  the  life  cycle 
of  ai.  aircraft  can  be  considered  to  be  an  acquisition  cycle  and 
an  operational  cycle.  The  applications  of  finite  element  models 
will  be  discussed  in  the  traditional  sequences  of  the  phases  in 
each  of  the  cycles. 

The  acquisition  cycle  normally  consists  of  five  phases  as 
defined  in  AFR  57-1.  These  include  the  conceptual,  demonstration 
and  validation,  full  scale  engineering  development,  production, 
and  deployment  phases.  Throughout  all  phases  of  the  aircraft 
acquisition  cycle,  the  Air  Force  reviews  aircraft  design  criteria 
and  requirments  through  a  design  review  process.  This  process  is 
necessary  to  ensure  that  the  aircraft  prime  contractor  is 
continually  complying  with  contract  design  and  performance 
specifications.  The  contractor  may  use  drawings,  reports. 
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analysis  or  test  results  to  show  that  design  criteria  are  being 
satisfied.  In  most  cases,  the  aircraft  prime  contractor  is 
responsible  for  the  finite  element  models  developed,  and  does  not 
necessarily  deliver  these  models  to  the  Air  Force  for  review, 
although  finite  element  modeling  and  analysis  may  have  been 
specified  tasks  in  the  product  development  contract.  The  Air 
Force  therefore  depends  on  the  judgment  of  the  contractor  that 
finite  element  models  and  their  results  are  valid  and  accurate. 
If  necessary,  the  Air  Force  may  instigate  parallel  studies  to 
validate  contractor  finite  element  models  and  analysis  results. 

The  conceptual  phase  begins  after  a  requirement  for  a 
system  has  been  identified  through  the  Operational  Requirement 
Process  (AFR  57-1).  During  this  phase  the  Casks  are  directed 
towards  identifying  and  exploring  alternative  solutions  or 
concepts.  Inputs  are  provided  by  all  participating  commands  to 
identity  candidate  solutions  and  tiieir  charac  tet  Is  t  ics .  The  lead 
organization  at  Aeronautical  Systems  Division  during  this  phase 
is  generally  the  Development  Plans  Organization  (ASD/XRH).  This 
office,  working  with  the  Secretary  of  the  Air  Force,  Di i ec lu t a te 
of  Advanced  Programs  (SAF/AQQ),  and  the  Air  Force  Laboratories, 
narrows  the  set  of  alternatives  so  that  additional  conceptual 
studies  and  analyses  can  be  conducted  through  contracts  with 
industry.  The  concepts  studied  prior  to  contract  initiation 
include  in-iinuse  parametric  designs  submitted  during  pre-proposal 
activities.  The  Design  Analysis  Directorate  (ASD/XRH)  has  the 
task  of  determining  the  feasibility  of  the  early  conceptual 
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realistic  extrapolations  from  analogous  dfsi;ns  df  aircralt 
sections,  such  as  a  wing  carry-through  box  with  a  pivoting  win>;. 
Accurate  weight  estimates  and  load  distributions  contribute  to 
reduced  development  costs  as  they  can  prevent  late  design  changes 
to  accoiT>n:iodate  the  early  over-optimistic  aircraft  weight 
predictions. 

The  contractors  performing  the  conceptual  studies  will 
develop  finite  element  models  commensurate  with  their  needs  for 
their  concept.  Preliminary  design  activities  involve  the 
evaluation  of  a  number  of  design  alternatives  in  order  to  most 
cost  effectively  satisfy  design  and  cost  objectives. 
Consequently,  it  is  necessary  to  maintain  versatility  at  each 
stage  of  the  preliminary  design  process,  since  the  entire  design 
concept  is  subject  to  change.  Preliminary  structural  analysis 
activities  may  include  the  creation  and  analysis  of  coarse  to 
medium  fidelity  finite  element  models.  These  models  are  use.!  to 
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deterrai''*-  the  mai^nltude  of  applied  loads,  define  the  initial 
stractural  member  sizing,  and  assess  the  structural  mass, 
stiffness  and  strength  of  the  airframe.  From  these  studies,  the 
design  concept  is  further  refined,  and  additional  structural 
design  criteria  are  derived. 

During  the  demonstration  and  validation  phase,  the  designs 
and  selected  candidate  solutions  are  further  refined  through 
continued  extensive  studies  and  analyses,  hardware  development, 
and  possible  tests  and  hardware  evaluations.  It  is  during  this 
period  that  the  design  responsibility  begins  to  transfer  to  the 
Systems  Program  Office  (SPO)  which  will  continue  the  task  with 
the  support  of  Development  Plans,  the  AFWAL,  and  other  Air  Force 
laboratories.  The  objective  of  this  phase  is  to  make  the 
decision  to  proceed  into  the  full  scale  engineering  development 
phase  (FSED)  on  a  selected  concept,  in  which  the  FSED  contractor 
develops  more  detailed  designs  of  the  aircraft  system  with  the 
intended  output  being,  as  a  minimum,  a  preproduction  system  that 
closely  approximates  the  final  product. 

As  the  design  iterates  towards  the  final  product,  finite 
element  models  are  further  refined  to  address  additional  sets  of 
requirements.  These  requirements  pertain  to  the  detailed  design 
of  structural  members,  life  prediction  and  durabilty  assessment, 
and  the  development  of  test  plans  and  structural  verification 
experiments.  These  artivites  require  the  use  of  high  fidelity 
f’nite  element  models,  which  are  often  qualified  and  correlated 
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wit*'  test  data.  Depending  on  the  application,  these  models  may 
significantly  reduce  the  aircraft  development  effort,  since 
contractors  may  use  analysis  results,  as  opposed  to  expensive  and 
time-consuming  hardware  tests,  to  show  that  structural  design 
criteria  are  being  satisfied.  As  each  of  these  criteria  are 
satisfied,  the  aircraft  structural  configuration  becom'cs  more 
detailed.  The  design  then  proceeds  onto  the  critical  and  final 
design  stages,  in  which  a  preproduction  design  i ;;  devel'U'ied.  Th>- 
preproduction  design  can  be  used  during  the  operational  test  and 
evaluation  phase,  which  is  generally  a  prerequisite  to  the 
production  decision. 

Before  the  operational  test  and  evaluation  phase  (OT&E) 
begins,  contractors  demonstrate  the  basic  flying  (jualities  and 
performance  of  the  aircraft  through  flight  tests,  generally  at 
the  Air  Force  Flight  Test  Center,  (AFFTC),  F.dwards  AFB, 
California.  The  AFFTC  is  the  responsible  organization  for  the 
support  of  the  contractor  demonstration  flight  tests.  They 
assist  the  SPO  and  the  contractors  in  planning  the  flight  test 
profiles,  the  instrumentation,  data  collection,  range  support 
during  the  tests,  and  post  flight  analyses.  The  AFFTC  personnel 
have  uses  for  finite  element  models  since  they  can  contribute 
significantly  by  reducing  the  time  required  for  the  AFFTC  test 
personnel  to  understand  the  new  aircraft,  to  be  able  to  calculate 
load  paths  through  the  aircraft,  and  to  provide  better  testing 
recommendations  to  the  contractor  on  flight  test  profiles  and 
instrumentation  requirements. 


8 


Flight  test  data  are  used  by  the  contractor  to  verify  the 
analytically  predicted  flight  performance  of  the  structure  and  to 
refine  the  finite  element  models.  The  models  may  be  altered  to 
better  correlate  with  flight  test  data,  to  better  define  specific 
operational  conditions,  or  to  address  required  structural  design 
modifications  determined  during  test.  As  the  models  gain 
additional  detail  and  more  accurately  simulate  the  structural 
behavior  of  the  operational  test  vehicle,  analytical  activities 
gain  additional  confidence.  It  is  therefore  possible  to  apply 
reliable  and  cost  effective  analytical  methods,  as  opposed  to 
experimental  methods,  to  show  that  additional  structural  design 
criteria  are  being  satisfied. 

The  OT&E  is  a  test  of  the  complete  weapon  system  including 
all  supporting  equipment.  This  test  is  conducted  in  as  realistic 
an  operational  environment  as  possible  to  estimate  the 
prospective  system's  military  utility,  operational  effectiveness 
and  operational  suitability.  The  OT&E  may  be  performed  by 
various  organizations,  and  the  data  obtained  can  be  used  to 
continually  update  the  finite  element  models  of  the  structure  so 
t  more  accurate  analytical  assessments  can  be  made. 
Adl'^ional  analyses  may  be  required  to  address  different 
op. rational  conditions  or  structural  modifications,  and/or  to 
further  optimize  the  structure.  Finite  element  models  must 
therefore  be  modified  or  created  as  required. 
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The  operational  cycle  begins  with  the  deployment  phase 
whereby  the  management  of  the  aircraft  structure  becomes  the 
responsibility  of  the  Air  Force  Logistics  Command.  The 
deployment  phase  encompasses  the  delivery  of  an  acceptable 
integrated  system  to  the  using  and  supporting  commands.  When  the 
Program  Management  Responsibility  Transfer  (PMRT)  occurs,  the 
aircraft  weapon  system  is  assigned  to  an  Air  Logistic  Center 
(ALC)  and  the  management  of  the  structure  resides  at  that  ALC 
during  Che  operational  life.  Inherent  in  the  PMRT  is  the 
transfer  of  responsibility  for  the  Aircraft  Structural  Integrity 
Program  (ASIP,  discussed  below)  from  the  Air  Force  System  Command 
(AFSC)  to  the  AFLC.  This  entails  a  transfer  of  the  finite 
element  analysis  capability  including  the  models  and  associated 
data.  To  facilitate  the  efficient  transfer  of  responsibility, 
the  models  must  be  complete  and  in  a  format  immediately  useful  to 
the  recipients. 

When  an  aircraft  is  placed  in  the  Air  Force  inventory,  it 
may  remain  operational  for  twenty  to  thirty  years.  During  this 
period,  the  ALC  and  other  Air  Force  organizations  will  perform  a 
number  of  activities  that  involve  finite  element  modeling  and 
analysis.  These  activities  include  the  evaluation  of  structural 
design  criteria  to  determine  new  mission  capabilities  (new 
requirement  alternatives  previously  addressed),  stores 
compatibility,  rapid  battle  damage  repair,  accident 
investigations,  structural  repair,  aircraft  structure  life 
extension,  and  new  materials  e  va  1  u.i  t  i  o  n.  i'urh  oi  :  hcse 
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.U'Livit^ies  reqii'rcs  riniti'  element'  raodelrf  with  v;irious  degrees  of 
detail  for  adaptati'".)  to  a  wide  scope  of  applications.  If  models 
are  not  accessible  to  the  responsible  Air  Force  organizations, 
they  must  be  purchased  from  the  aircraft  contractor. 

Ouring  the  operational  cycle,  the  Operational  Commands  and 
Headquarters  USAF  continue  to  perform  Mission  Area  Analyses  (per 
AFR  57-1),  whereby  existing  deficiencies  may  be  identified  in  the 
structure.  These  deficiencies  may  arise  from  a  change  of 
mission,  change  of  threat,  development  of  a  new  weapons  system, 
or  an  obsolescence  of  an  aircraft  due  to  age.  In  some  cases,  the 
deficiency  may  best  be  solved  by  modifying  an  existing  aircraft 
to  perform  the  new  mission  through  the  addition  of  a  new  store, 
modification  of  the  airframe  for  a  longer  life,  the  strengthening 
of  the  airframe  to  withstand  the  new  mission  or  tactic,  or  the 
installation  of  a  new  weapons  system.  The  Headquarters  Air  Force 
Logistics  Command  currently  lists  in  excess  of  twenty  major 
modifications  to  operational  aircraft  that  affect  the  structure. 
Depending  on  the  type  and  extent  of  the  modification  (i.e.  major 
modifications  verses  Class  II  modifications),  various 
organizations  may  have  responsibility  for  the  creation  or 
modification  of  finite  element  models  to  examine  structural 
design  criteria.  These  organizations  may  include  various  groups 
within  the  Air  Force,  or  a  contractor  (which  may  or  may  not  be 
the  prime  contractor  for  the  aircraft). 

The  discussion  on  the  applicability  of  finite  element 


models  thus  far  has  followed  Che  activities  in  the  sequence  of 
phases  In  Che  aircraft  life  cycle.  There  are  also  numerous 
applications  of  finite  element  models  which  occur  continual  ly 
during  the  development  and  operational  cycles  of  .in  aircraft. 
These  applications  Include  the  assessment  of  ri' liability  and 
maintainability,  stores  compatibility  and  cert  i  f  i  c.at  i  on ,  and 
technology  base  development. 

Reliability  and  ma  i  n  t  a  Inab  i  I ;  t  v  .-ri-  cons  idc  ralil  c  life  cycle 
cost  drivers.  Early  in  the  life  cycle,  con.s  i  dt^  ra  t  i  oiis  are  given 
CO  the  aircraft  structural  integrity  .ind  its  maintenance 

throughout  its  operational  life.  The  Aircraft  Structural 
Integrity  Program  (ASIP),  directed  by  APR  80-13,  has  the 

objective  to  assure  the  structural  integrity  of  aircraft 
structure,  including  airframe  strength,  rigidity,  damage 
tolerance,  durability,  and  economic  life.  Aircraft  structures 
are  analyzed  to  determine  damage  tolerance  as  a  function  of 

specified  mission  profiles,  flying  time,  and  other  operational 

raeasureables,  such  as  landings  or  weapon  deliveries  (e.g.  dive 
bomb  runs).  These  analyses  will  determine  the  minimum  inspection 
interval  for  the  aircraft  and  its  maximum  predicted  utility,  and 
can  be  used  to  modify  the  structure  to  increase  its  durability 
and  reduce  its  inspection  frequency.  The  ASIP  can  greatly  reduce 
the  aircraft  life  cycle  cost.  Increase  the  aircraft  combat 
availability,  and  enhance  its  safety.  ASIP  requirements  are 
included  in  the  procurement  documentation  for  each  aircraft  and 
considerations  for  the  ASIP  are  included  in  each  development 
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phase  from  conceptual  through  production.  The  ASIP  is  updated  to 
include  any  structural  modifications  to  the  aircraft  or  changes 
in  mission  which  may  occur  during  its  operational  life. 

Finite  element  models  have  broad  application  in  the  ASIP 
program.  Typically,  the  aircraft  prime  contractor  is  responsible 
for  the  models  and  analyses,  although  various  Air  Force 
organizations  may  use  these  models  to  perform  specific  analytical 
tasks.  The  models  used  for  these  studies  must  be  highly  detailed 
in  order  to  properly  describe  the  stress  field  in  the  component 
of  interest.  As  a  result,  it  is  often  necessary  to  refine 
existing  finite  element  models,  or  create  new  models  to 
adequately  support  these  studies.  Generally,  stress  results 
obtained  through  finite  element  analyses  must  be  post-processed 
with  a  variety  of  stand-alone  programs  to  further  assess  crack 
initiation,  crack  growth,  or  fatigue  life. 

Stores  compatibility  and  certification  is  a  repeated  effort 
throughout  the  aircraft  life  cycle  to  address  mission  changes, 
added  capabilities,  or  the  introduction  of  new  weapons  to  the  Air 
Force  inventory.  The  Aircraft  Compatibility  Office  (Seek  Eagle) 
analyzes  the  aircraft-store  corapatabili ty ,  and  certifies  these 
combinations  prior  to  flight  testing.  Finite  element  analyses 
must  be  conducted  on  aircraft  systems  with  stores  since  these 
stores  may  alter  the  structural  characteristics  of  the  system. 
Typically,  high  fidelity  models  are  used  for  structural  dynamic 
and  aerodynamic  analyses  to  determine  the  structural  integrity  of 
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components  under  various  operational  conditions.  It  is  often 
necessary  to  adapt  finite  element  models  provided  by  different 
contractors  (i.e.  the  aircraft  prime  contractor  and  the  store 
contractor)  to  perform  these  studies. 

The  technology  base  provides  the  capabilities  to  support 
current  systems  and  to  address  the  technical  needs  of  future 
systems.  The  Air  Force  Systems  Command  (AFSC)  represents  the 
laboratories  that  contribute  heavily  to  aircraft  structures 
technology  development,  and  maintain  centers  of  excellence  that 
provide  support  to  other  Air  Force  organizations  throughout  the 
aircraft's  life  cycle.  Among  its  multiple  areas  of  technical 
responsibility,  the  AFSC  Flight  Dynamics  Laboratory  performs 
analytical  and  experimental  programs  to  validate  advanced 
structural  design  concepts,  to  investigate  payoffs  of  new  design 
concepts  and  materials  usage,  and  to  develop  the  technology  base 
in  structures.  Each  of  these  activities  requires  the  use  of 
finite  element  models  of  various  levels  of  detail.  For  example, 
structural  optimization  codes  allow  aircraft  designers  to 
minimize  structural  weight  of  the  aircraft  system,  while 
maintaining  structural  design  criteria.  This  capability  would 
not  be  feasible  without  the  use  of  finite  element  analysis. 
Although  this  capability  may  be  initially  developed  with 
simplified  representative  models,  finite  element  models  of  real 
operational  aircraft  are  often  needed  to  validate  the  new 
technical  capabilities  under  practical  conditions. 
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As  described  above. 


finite  element  models 


are  used 


throughout  the  aircraft  life  cycle.  These  models  provide  an 
efficient  means  by  which  structural  design  criteria  can  be 
verified,  thereby  reducing  the  dependence  on  costly  and  time- 
consuming  hardware  tests.  In  order  to  develop  the  technology 
base  which  allows  the  application  of  finite  element  analysis  tc 
be  a  useful  tool  during  the  product  development  and  operational 
cycles,  it  is  also  necessary  to  validate  new  technologies  with 
finite  element  models.  As  new  technologies  evolve,  finite 
element  methods  will  allow  for  the  more  efficient  design  and 
development  of  aircraft  structures,  and  will  continue  to  have 
widespread  application  throughout  the  aircraft  life  cycle.  The 
use  of  finite  element  techniques  and  models  will  therefore 
increase  as  new  applications  are  developed. 

A  centralized  database  of  finite  element  models  can  promote 
the  efficient  use  of  finite  element  methods,  and  allow  for  the 
efficient  access  of  finite  element  data  by  the  various 
organizations  which  need  them  when  they  are  needed.  Currently, 
there  is  no  standard  procedure  within  the  Air  Force  by  which 
finite  element  data  may  be  obtained  by  the  various  organizations. 
This  creates  a  condition  whereby  highly  advanced  capabilities  may 
exist  for  these  organizations  to  perform  their  technical  tasks, 
however,  due  to  lack  of  data  in  the  proper  form,  the  advantages 
of  this  technical  base  are  potentially  lost.  Aircraft 
development  and  operational  costs  may  increase,  since  technical 
tasks  may  not  be  performed  with  the  most  efficient  methods,  or 
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may  be  performed  with  less  than  desirable  methods.  It  is 
therefore  necessary  to  examine  the  organizational  management  of 
finite  element  models  by  the  various  Air  Force  organizations  to 
determine  the  areas  for  potential  improvement  through  the 
application  of  a  centralized  database. 
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3.  ORGANIZATIONAL  MANAGEMENT  OF  FINITE  ELEMENT  MODELS 


Rev  individuals  in  a  number  of  Air  Force  organizations  were 
contacted  to  determine  the  extent  to  which  finite  clement  models 
are  used,  and  the  methods  by  which  these  models  are  managed 
within  and  among  organizations.  These  organizations  represented 
a  cross  section  of  those  having  the  capability  to  perform  finite 
e  I ‘^"'."'■'1;  analyses,  and  those  who  require  finite  element  data  to 
accomplish  their  tasks.  These  organizations  cover  the  activities 
required  across  the  aircraft  life  cycle.  Specifically,  the 
following  Air  Force  organizations  were  contacted: 

0  Wr ight-Patterson  AFB  (AFWAL),  Ohio 

*  Flight  Dynamics  Laboratory 

*  Aerop ropul s ion  Laboratory 

*  Aeronautical  Systems  Division 

Development  Plans 

Systems  Engineering  -  Survivability 
4950th  Test  Wing 

*  Headquarters  Air  Force  Logistics  Command  (AFLC) 

-  Weapons  System  Master  Plans 
Major  Aircraft  Modifications 

-  Packaging  Evaluation  Agency 
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o  Air  Logistics  Centers 

*  Warner  Robins  AFB,  Georgia 

*  Hill  AFB,  Ogden,  Utah 

*  McClellan  AFB,  Sacramento,  California 

*  Kelly  AFB,  San  Antonio,  Texas 

*  Tinker  AFB,  Oklahoma  City,  Oklahoma 

o  Armament  Division,  Eglin  AFB,  Florida 

*  3246  Test  Wing 

*  Aircraft  Corapatiblity  Office  (Seek  Eagle) 

o  Air  Force  Flight  Test  Center,  Edwards  AFB, 
California 

0  Inspector  General,  Norton  AFB,  California 


The  primary  objective  in  our  discussions  with  these 
organizations  was  the  examination  of  current  organizational 
procedures  for  the  management  of  finite  element  models,  and  the 
possible  applications  of  a  centralized  database  of  models  within 
these  organizations.  Although  the  scope  of  activities  among 
these  organizations  varies  considerably,  a  centralized  database 
must  be  adaptable  to  each  of  their  respective  needs.  Therefore, 
the  requirements  for  any  centralized  database  of  finite  element 
models  must  address  the  aggregate  needs  of  the  user  community. 
General  findings  concerning  the  source,  acquisition,  use, 
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storage,  communication  and  transport  ot  finite  element  data  are 
discussed  below.  These  findings  may  or  may  not  apply  across  the 
board  to  specific  organizations,  depending  on  their  specific 
applications  of  finite  element  data. 

The  sources  of  finite  element  models  for  these 
organizations  are  primarily  the  aircraft  manufacturer. 
Typically,  the  Air  Force  does  not  require  the  delivery  of  finite 
element  models  in  a  standard  format  in  the  product  development 
contract.  Therefore,  certain  Air  Force  organizations  are 
required  to  obtain  or  create  these  models  when  they  are  needed  to 
address  specific  analysis  reqireraents  during  various  operational 
stages.  Over  the  life  cycle  of  an  aircraft,  the  identical  finite 
element  model  of  an  aircraft  system  or  component  may  have  been 
purchased  from  the  contractor  several  times  by  different 
organizations,  even  though  the  development  of  this  model  may  have 
been  initially  funded  by  the  Air  Force  under  the  product 
development  contract.  On  some  occasions,  it  was  found  that  the 
Air  Force  is  prohibited  from  accessing  finite  element  data  and/or 
performing  analyses  through  limited  rights  clauses  imposed  on 
this  data.  Since  the  Air  Force  does  not  own  this  data,  finite 
element  models  may  also  be  repurchased  from  the  contractor 
several  times  with  only  minor  changes.  The  lack  of  a 
configuration  controlled  set  of  finite  element  data  available  to 
various  Air  Force  organization"  at  the  time  the  aircraft  is 
placed  in  the  inventory  results  in  organizational  inefficiencies 
which  may  increasi'  the  operational  costs  of  an  a  ire  raft. 
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Finite  element  models  which  are  obtained  from  Air  Force 


contractors  are  subject  to  typical  government  contracting 
procedures,  in  which  the  contractor  must  respond  to  a  Statement 
of  Work  to  deliver  the  model.  The  Air  Force  may  need  this  data 
within  a  scheduled  time  frame  in  order  to  support  key  technical 
decisions  which  properly  consider  the  various  technical 
alternatives.  To  reduce  lead  time  in  acquiring  these  models,  and 
thereby  increase  analysis  time  to  examine  design  alternatives, 
finite  element  raodeis  must  be  readily  available.  The  necessity, 
time,  and  cost  of  procurement  of  finite  element  models  from  Air 
Force  contractor  organizations  may  be  prohibitive.  These 
activities  restrict  the  application  of  finite  element  analysis  by 
Air  Force  organizations,  and  may  indirectly  increase  product 
development  and  operational  costs. 

When  models  are  obtained  from  the  aircraft  manufacturer, 
they  typically  lack  adequate  documentation  which  will  aid  the 
analyst  in  understanding  the  models  so  that  he  may  perform  his 
specific  study.  The  extent  of  the  model  documentation  is 
currently  at  the  discretion  of  the  aircraft  manufacturer.  The 
Air  Force  generally  does  not  require  the  aircraft  manufacturer  to 
provide  a  standard  set  of  documentation  which  can  be  used  to 
judge  the  adequacy  of  the  model  and  its  analysis  results.  The 
responsible  analyst  must  therefore  spend  considerable  effort  in 
understanding  the  model  and/or  performing  analyses  to  ensure  the 
adequacy  of  the  delivered  model.  In  many  instances,  he  must  also 
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Iii-.irt'  thi-  ri'spiMis  i  !i  1 1*  i  n.l  i  v  i  ilu.i  !  wtm  c'r(",!te<i  iho  modi'*]  witJn'n 
t.ho  concract-or  origan  izat  ion  to  completely  understand  the  model 
a.:ui  its  ri'snlts.  The  lack  of  standard  and  concise  mode] 
do camen r a t i on  may  therefore  impede  current  and  future  studies, 
caus.‘  unwarrantt;d  d.eiays,  promote  inappropriate  analyses,  and 
sjppiirt  iri'/aiid  conclusions,  if  tlie  model  and  its  documentation 
are  misunderstood. 

Air  Forc>>  i'rc,an  izat  ions  and  aircraft  manufacturers 
generally  use  lifferent  finite  element  modeling  and  analysis 
s.'.’tvare,  installed  on  different  computing  machinery.  It  is 
thererore  difficult  to  specify  a  single  format  for  the  deiiverv 
:  i ’1  i  t  e  element  models.  The  Air  Force  organization  receiving 
mod'*;  may  ne.- 1  to  convert  the  delivered  finite  element  data 
t j  a  format  that  can  be  used  on  site.  If  format  conversion  is 
risjuired,  the  responsible  analyst  may  spend  weeks  attempting  to 
understand  the  i  n  i  t  e  i-lement  data,  and  developing  the  software 
necessary  to  properly  convert  the  modi’l  to  a  useful  format.  This 
IS  especially  true  if  t!ie  analyst  is  not  familiar  with  tlie  finite 
el-'ment  software  used  by  the  contractor.  Format  conversion  can 
be  a  lengthy  process,  since  the  model  must  be  properly  qualified 
to  ensiire  tile  integrity  of  the  resulting  model  before  it  is  used 
for  other  a pp 1  i  c a t  ions .  This  is  done  by  performing  many  modeling 
checks  and  analyses  to  match  the  analysis  results  obtained  by  the 
contractor.  it  qualification  procedures  are  not  adequate,  the 
analyst  may  inadvertantly  perform  analyses  on  an  invalid  or 
uncorrel  ated  model.  The  use  of  different  computer  liardware  and 


sofrware  among  Air  Force  and  contractor  organizations,  although 
impossible  to  control,  is  a  further  restriction  on  the 
applicability  of  finite  element  raodels- 

Finite  element  models  are  typically  acquired  for  a  specific 
purpose  and  are  generally  managed  by  a  single  individual  within 
an  Air  Force  organization.  This  individual  may  use  his  own 
software  for  converting  the  model  format,  and  implement  his  own 
procedure  for  qualifying  the  model.  He  mav  then  modify  the  rnodi'l 
to  suit  his  specific  needs,  and  perform  an  ap.alysis.  When  he*  has 
completed  the  study,  the  analyst  typically  is  responsible  for 
storing  the  model  on  tape,  and  maintaining  the  model 
documentation.  Throughout  the  Air  Force,  many  different 
individuals  use  finite  element  models  to  address  maiiy  differc'nt 
applications.  It  is  therefore  difficult  to  locate  these 
individuals  and  maintain  awareness  of  their  activities.  If 
finite  element  models  are  needed,  it  is  typically  necessary  to 
contact  the  indi vidua  1 ( s )  responsible  for  the  models  within  an 
organization,  causing  a  condition  whereby  there  are  possibly 
numerous  sources  of  finite  element  models  within  the  Air  Force. 
Since  the  aircraft  life  cycle  may  last  several  years,  the 
individual  originally  responsible  for  the  finite  element  model 
may  no  longer  be  a  part  of  the  organization,  requiring 
considerable  re-learning  by  the  responsible  analyst.  The  lack  of 
a  standard  mechanism  for  sharing  finite  element  data  can  can 
result  in  increased  costs  through  the  duplication  of  effort,  the 
repurchase  of  finite  element  data  from  a  contractor,  or  the 


22 


application  of  less  than  desirable  approaches  to  the  solution  of 
certain  problems. 

Certain  organizations  lack.  the  personnel,  software, 
computing  machinery,  and/or  budget  to  perform  extensive  finite 
element  modeling  and  analyses,  however,  if  this  data  were  readily 
available,  it  could  better  serve  the  technical  needs  of  their 
programs.  For  example,  the  packaging  of  aircraft  components  for 
shipment  by  the  ALC  does  not  currently  employ  extensive  finite 
element  analyses,  and  must  therefore  rely  on  expensive  and  time- 
consuming  hardware  tests.  Finite  element  data  may  be  used  by  the 
package  designer  to  gain  further  insight  on  the  structural 
behavior  of  the  item  which  must  be  packaged,  and  facilitate  the 
development  of  testing  procedures.  Finite  element  techniques  may 
also  be  employed  to  optimize  the  design  and  weight  of  the 
packaging  material  itself,  resulting  in  higher  quality  package 
designs  and  lower  shipping  costs.  This  is  only  one  example  out 
of  the  many  possible  applications  of  finite  element  data  by 
organizations  which  are  off-line  from  the  primary  aircraft 
development  effort.  Various  other  organizations  and  activities 
may  find  additional  uses  of  finite  element  data  if  this  data  were 
readily  available. 

The  management  of  finite  element  models  throughout  the  Air 
Force  appears  to  be  driven  by  the  applications  which  access  these 
models.  This  is  exemplified  by  the  fact  that  each  user  requires 
finite  element  models  with  the  minimum  detail  to  satisfy  his 
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immedi.iCP  problem  ond  formatted  to  operate  on  the  computers  and 
software  available  within  his  organization.  The  tiany  specialized 
uses  of  finite  element  models  by  geographically  separate 
organizations  that  have  specialized  uses  for  them  has  caused  a 
wide  proliferation  of  finite  element  models  throughout  the  Air 
Force,  such  that  they  are  difficult  to  efficiently  and 
economically  manage  across  organizations.  This  has  led  to 
considerable  duplication  of  effort,  inappropriate  analyses, 
miscommunication,  and  increased  costs  over  the  aircraft  life 
cycle.  Although  a  centralized  database  of  finite  element  models 
cannot  address  all  of  the  problems  associated  with  the 
organizational  management  of  these  models,  it  can  introduce  an 
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Force  organizations,  considerable  benefits  in  efficiency, 
expediency,  and  costs  can  be  realized. 
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4.  APPLICATIONS  OF  A  CENTRALIZED  DATABASE 


The  use  of  a  database  as  a  central  repository  for  finite 
element  models  which  can  be  accessed  throughout  the  Air  Force 
respresents  a  fundamental  change  in  approach  to  the  management  of 
these  models.  Currently,  considerable  emphasis  is  placed  on  the 
management  of  the  applications  software  which  use  this  data  (e.g. 
finite  element  modeling  and  analysis  codes,  computer  programs, 
etc.),  however,  little  or  no  emphasis  is  placed  on  the  management 
of  the  data  itself.  The  database  approach  recognizes  that  the 
management  of  finite  element  data  is  also  a  necessary  function  to 
ensure  engineering  efficiency  throughout  the  aircraft  life  cycle. 
The  possible  applications  of  such  a  database  are  discussed 
below. 


A  centralized  database  of  finite  element  models  can  have 
wide  application  during  the  aircraft  development  cycle.  If 
finite  element  models  were  required  from  the  aircraft  prime 
contractor  in  a  standard  format  with  standard  documentation  for 
delivery  at  each  stage  of  aircraft  development,  the  Air  Force 
could  benefit  by  obtaining  better  abilities  to  perform  technical 
monitoring  and  program  management  tasks  during  each  stage  of 
aircraft  development.  Access  to  these  models  would  allow  the  Air 
Force  to  examine  in  detail  the  finite  element  modeling 
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assumptions  and  the  quality  of  the  analyses  performed  by  the 
contractor.  Consequently,  the  contractor  may  put  more  effort 
into  the  development  of  these  models,  thereby  increasing  the 
technical  quality  of  analyses  performed.  The  Air  Force  may  also 
obtain  greater  control  over  the  technical  direction  of  the 
aircraft  development  program,  taking  a  more  active  role  in  the 
evaluation  of  structural  design  criteria. 

A  centralized  database  could  contain  a  complete  set  of 
finite  element  models  developed  during  the  various  stages  of 
aircraft  development  which  can  be  used  as  a  historic  database  of 
technical  data.  This  database  can  add  further  insight  to  the 
technical  direction  of  the  development  program,  and  be  used  for 
guidance  in  making  future  technical  decisions.  The  technology 
base  required  for  the  support  of  current  and  future  aircraft  can 
be  improved  through  the  evaluation  of  lessons  learned  throughout 
the  development  programs  of  similar  aircraft.  This  would  allow 
for  the  better  technical  planning  and  assessment  of  technical 
risks  when  new  aircraft,  or  new  derivatives  of  aircraft,  are 
being  investigated. 

During  the  aircraft  operational  cycle,  a  centralized 
database  can  facilitate  the  transfer  of  finite  element  data 
across  Air  Force  organizations.  If  finite  element  models  and 
documentation  were  obtained  from  the  contractor  and  stored  in  a 
database  when  the  aircraft  is  placed  in  the  inventory,  this  data 
could  be  readily  available  to  all  Air  Force  organizations  when  it 


26 


is  needed.  Procurement  lead  time  and  costs  can  be  reduced,  since 
the  Air  Force  would  be  relieved  from  having  to  purchase  finite 
element  models  from  the  contractor  several  times  over  the  life 
cycle  of  the  aircraft.  Since  this  database  would  be  centrally 
located,  the  various  organizations  which  need  finite  element  data 
could  communicate  with  only  one  source,  as  opposed  to  the 
numerous  sources  which  are  currently  relied  upon.  The  impact  of 
organizational  changes  on  the  finite  element  data  acquisition 
process  would  also  be  minimized  as  a  result. 

A  centralized  database  of  finite  element  data  would  allow 
the  Air  Force  to  better  evaluate  structural  design  criteria 
before  decisions  are  made  to  commit  development  funds  towards 
certain  activities.  If  enhancements  or  modifications  to  the 
aircraft  system  are  necessary,  technical  specifications  and 
performance  criteria  could  be  better  stipulated  to  competing 
contractors  in  the  Request  for  Proposal,  allowing  for  reduced 
development  costs.  In  many  cases,  finite  element  data  for 
components  which  are  being  considered  for  modification  are 
currently  the  property  of  one  of  the  contractors.  Portions  of 
this  data  are  often  necessary  for  dissemination  to  the  entire 
contractor  community  to  promote  open  competition.  The 
availability  of  this  data  to  the  Air  Force  in  a  centralized 
database  would  allow  the  Air  Force  to  perform  analyses  and 
selectively  disseminate  the  needed  information  to  the  contractor 
community,  thereby  reducing  the  reliance  on  the  single  contractor 
which  owns  the  information.  When  an  implementation  contractor  is 
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selected,  the  Air  Force  could  supply  the  needed  finite  element 
data,  relieving  the  contractor  from  subcontracting  to  a  third 
party  to  obtain  this  information. 

The  applications  of  a  centralized  database  of  finite  element 
models  discussed  above  are  the  result  of  only  a  cursory 
examination  of  finite  element  usage  throughout  the  Air  Force  over 
the  life  cycle  of  various  aircraft.  When  such  a  database  is 
eventually  Implemented,  numerous  other  applications  may  become 
evident.  The  design  of  such  a  database  should  consider  each  of 
these  applications  in  the  development  of  database  performance 
requirements. 
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5.  CENTRALIZED  DATABASE  REQUIREMENTS 


A  number  of  requirements  must  be  imposed  on  a  centralized 
database  of  finite  element  models  to  ensure  its  applicability  to 
various  Air  Force  organizations  over  the  many  years  in  the 
aircraft  life  cycle.  Of  primary  importance  is  the  fact  that  the 
centralized  database  must  continually  address  an  evolving  set  of 
user  needs  throughout  its  forseeable  lifetime.  Therefore,  the 
centralized  database  must  have  built-in  versatility  to  be  applied 
to  new  applications  and  new  technological  advances  as  they  occur. 
This  versatility  applies  to  new  developments  in  finite  element 
modeling  and  analysis  software,  database  software,  graphics 
capabilities,  computer  hardware  or  other  peripherals. 
Versatility  can  only  be  accomplished  through  the  careful 
development  of  database  requirements  in  the  preliminary  planning 
s  tages. 

One  of  the  fundamental  requirements  of  the  finite  element 
model  database  is  the  storage  of  data  so  that  it  can  be 
selectively  and  efficiently  accessed.  This  requirement  implies 
that  the  database  should  be  located  on  a  central  computer  at  a 
centralized  location,  such  as  AFWAL,  allowing  many  users  to 
either  access  the  database  directly  on  site,  or  remotely  through 
high  speed  data  transmission  lines.  The  central  computer  does 
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not  necessarily  have  to  be  a  single  computer,  since  future  trends 
in  database  management  include  the  development  of  distributed 
databases  which  may  reside  on  different  computers,  accessible  via 
network.  The  location  of  finite  element  data  at  a  central 
location  will  minimize  the  need  for  users  to  communicate  across 
organizations.  Users  would  therefore  have  a  single  source  and  a 
standard  procedure  by  which  they  may  obtain  finite  element  data- 
Technical  support  of  the  database  would  also  be  minimized  if  it 
were  centrally  located. 

Since  the  various  Air  Force  organizations  have  particular 
requirements  for  the  evaluation  and  application  of  finite  element 
data,  it  is  necessary  to  incorporate  a  database  schema  which  is 
easily  interpreted  by  the  user  community.  The  database  schema  is 
the  method  by  which  the  data  is  represented  in  the  database.  In 
an  open  database  architecture,  it  is  necessary  to  allow  users  the 
ability  to  retrieve  that  information  which  is  most  useful  to  them 
in  the  form  that  is  most  useful  to  them.  This  ability  will 
facilitate  the  transfer  of  finite  element  data  among 
organizations  which  utilize  different  applications  software  (e.g. 
finite  element  modeling  and  analysis  software,  computer  programs, 
etc.),  and  facilitate  the  development  of  new  applications  which 
use  this  data. 

The  centralized  database  must  allow  for  the  manipulation  and 
presentation  of  data  so  that  it  can  effectively  support  the  user 
community  and  promote  data  sharing.  This  implies  that  the 
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dat.ibase  will  incorporate  a  consistent,  user-friendly,  menu- 
driven  interface  to  allow  users  to  view  and  manipulate  data  in 
the  formats  which  have  meaning  to  them  with  minimum  training.  In 
terras  of  hardware,  graphics  and  terminal  drivers  should  support 
the  existing  installed  base  of  computer  hardware  and  peripherals, 
as  well  as  maintain  versatility  to  support  additional  new 
hardware  capabilities  as  these  become  available.  In  terms  of 
software,  the  database  should  support  finite  element  formats  and 
other  applications  which  are  currently  being  used  by  the  Air 
Force,  as  well  as  maintain  adaptability  to  additional  new 
software  capabilities  as  they  are  developed. 

The  database  should  also  protect  data  to  ensure  its 
security,  reliability,  consistency,  and  correctness.  Models 
which  are  initially  stored  in  the  database  should  therefore  be 
subject  to  some  standard  qualification  procedures  to  ensure  that 
the  models  will  be  operational  when  delivered  to  the  end  user. 
While  resident  in  the  database,  the  models  should  not  be  allowed 
to  be  modified  by  users  without  proper  authority.  Furthermore, 
the  database  should  guard  against  unauthorized  access  to 
classified  or  proprietary  data. 

In  order  to  facilitate  its  implementation,  the  database 
should  utilize  existing  software  whenever  possible,  and  be 
adaptable  to  a  variety  of  machines.  The  use  of  an  existing 
database  management  system,  executive  system,  user  interface  and 
database  schema  allows  for  lower  development,  operational,  and 
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maintenance  costs  over  the  lifetime  of  the  database,  since  the 
support  of  these  components  will  be  the  responsibility  of  various 
third  party  private  vendors  and/cr  government  organizations. 
Machine  independence  is  also  a  key  requirement  due  to  the 
evolving  nature  of  computer  hardware.  The  database  should 
therefore  be  implemented  with  an  operating  system  which  allows 
for  the  installation  on  various  computers,  such  as  UNIX. 

The  above  requirements  define  the  direction  for  database 
development  and  implementation  activities,  from  which  detailed 
specifications  for  the  database  software  can  be  derived.  At  this 
early  stage,  no  attempt  is  made  at  defining  the  detailed 
specifications  since  the  database  architecture  has  not  yet  been 
finalized.  A  database  architecture  must  therefore  be  developed 
which  satisfies  each  of  the  above  requirements  in  order  to  be 
fully  operational. 
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6.  CENTRALIZED  DATABASE  ARCHITECTURE 


A  suggested  means  by  which  a  centralized  database  of  finite 
element  models  can  be  made  available  for  dissemination  throughout 
the  Air  Force  is  shown  in  the  schematic  diagram  in  Figure  6-1. 
This  database  architecture  incorporates  a  modular  design, 
allowing  for  the  addition  of  new  capabilities  with  minimum  impact 
on  existing  ones.  The  salient  feature  of  this  database 
architecture  is  the  definition  of  two  separate  databases,  one  of 
which  includes  only  information  about  the  models,  the  other,  the 
models  themselves.  This  dual  database  architecture  is  at  the 
heart  of  the  centralized  finite  element  database  proposed  for 
implementation  by  the  Air  Force.  Essentially,  the  information 
database  acts  as  a  central  catalogue  containing  certain 
information  which  will  aid  the  user  in  making  decisions  to  cither 
adapt  all  or  part  of  an  existing  finite  element  model  to  his 
particular  application,  or  build  his  own  finite  element  model. 
The  model  database  acts  as  a  central  repository  of  finite  element 
models  which  can  be  accessed  as  a  library  by  users  throughout  the 
Air  Force.  The  dual  database  architecture  is  advantageous  over  a 
single  database  containing  only  finite  element  models  with  regard 
to  the  model  identification  and  selection  process,  computer 
system  on-line  resource  requirements,  and  data  security.  These 
advantages  and  additional  capabilities  of  the  suggested  database 
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architecture  are  discussed  below. 

The  finite  element  model  identification  and  selection 

process  with  a  single  model  database  would  be  cumbersome  since 
database  users  would  have  difficulty  in  identifying  the 
particular  models  which  are  of  interest  to  them.  Users  would  be 
required  to  examine  individual  data  records  within  the  models, 
and/or  load  the  models  locally  for  further  examination. 
Moreover,  the  finite  element  bulk  data  deck  does  not  necessarily 
contain  sufficient  information  to  fully  describe  the  model,  since 
a  large  amount  of  information  about  the  models  cannot  be 
extracted  through  the  examination  of  the  models  alone.  This 
information  includes  descriptive  data  (e.g.  product  data,  mass, 
application,  material  identification,  etc.),  analysis  data  (e.g. 
type  of  model,  type  of  analyses  conducted,  rationale  for  model 
configuration,  etc.),  or  other  identifiers  (e.g.  creation  date, 

drawing  references,  owner,  revision  number,  etc.)  A  dual 

database  archictecture  streamlines  the  model  identification  and 
selection  process  since  the  information  database  would  provide 
only  summary  and  catalogue  information  that  could  be  used  as 
criteria  for  model  selection.  Consequently,  users  could  examine 
many  different  finite  element  models  and  many  more  modeling 
alternatives  before  down-selecting  to  the  appropriate  finite 
element  model. 

A  singl'^  mode]  database  would  require  the  on-line  storage  of 
each  data  rec'ird  fijr  all  finite  element  models.  This  would  be 


necessary  since  database  users  would  be  interacting  directly  with 


model  data  tor  identification  and  selection  purposes.  Tlie 
extensive  amount  of  on-line  information  required  to  retain  all 
models  within  a  single  model  database  would  have  penalties 
associated  with  system  resource  requirements.  In  particular,  a 
large  amount  of  disk  space  would  be  required  for  storing  the 
models,  and  the  system  central  processor  could  be  overloaded  due 
to  possibly  large  numbers  of  users  performing  extensive  search 
and/or  extraction  operations  on  possibly  large  numbers  of  models. 
The  effectiveness  of  a  centralized  database  consisting  of  on-line 
model  data  would  therefore  be  closely  tied  to  the  type  of 
computer  system  on  which  it  was  installed.  In  this  event,  growth 
of  the  model  database  would  also  require  growth  of  tr.e  computer 
system.  A  dual  database  architecture  would  minimize  system 
resource  requirements  since  users  would  be  interacting  with  the 
smaller  subset  of  data  in  the  information  database.  Problems 
associated  with  extensive  on-line  storage  and  processor 
requirements  are  alleviated  since  the  larger  model  database  can 
be  stored  off-line  in  a  library  (i.e.  on  tapes  or  other  mass 
storage  media),  to  be  loaded  only  when  models  are  requested  for 
delivery  to  the  user. 

In  the  event  that  users  were  interacting  with  a  single  model 
database,  it  would  be  difficult  to  protect  proprietary  or 
classified  data  which  may  be  written  into  the  finite  element 
model  bulk  data  deck.  A  dual  database  structure  is  not  a  panacea 
for  all  model  security  issues;  however,  since  users  will  be 
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i  n  1 1  i‘ac  L  i  ag  'iniv  wiLii  ci.ita  about  the  models  in  the  information 
database,  it  is  possible  to  protect  proprietary  or  classified 
data  to  some  extent.  An  information  database  can  be  configured 
whicli  will  allow  uS'Ts  to  view  only  that  data  which  has  been 
cleared  for  dissemination  throughout  the  finite  element  analysis 
community.  I:  sensitive  information  is  contained  in  the  finite 
element  bulk  data  d<?ck,  this  information  can  be  password 
protected,  or  the  user  could  be  alert"d  to  this  fact,  and  be 
given  the  ident  if  icat  ic'in  of  the  appropriate  point  of  contact  to 
properly  clear  this  information  in  the  event  that  additional 
model  details  are  necessary. 

The  dual  database  structure  consisting  of  an  information 
database,  on  which  interactive  operations  could  be  conducted,  and 
a  model  database,  which  consists  of  an  off-line  library  of  finite 
element  models  has  numerous  other  advantages  over  a  single  model 
database  architecture.  It  is  anticipated  that  the  information 
database  will  be  an  industry  standard  relational  database,  such 
as  ORACLE,  which  incorporates  SQL  (Structured  Query  Language)- 
SQL  is  a  non-p  rocedij  ra  1 ,  unified  language  which  allows  users  to 
easily  define,  access,  manipulate  and  control  data  in  the 
database.  The  information  database  will  also  utilize  an  industry 
standard  logical  data  model,  such  as  the  Air  Force  IDEF  model. 
The  IDEF  methodology  provides  a  systematic  approach  for  analyzing 
and  documenting  functional  requirements  and  data  relationships 
among  the  entries  in  the  information  database.  The  use  of  an 
existing  relational  database  management  system  and  logical  data 
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model  assures  compatibility,  portability,  connectabili Cy ,  and 
capability  of  the  centralized  database  and  its  contents  over  its 
lifetime.  The  initial  development  and  operational  costs  for  the 
centralized  database  will  be  minimized  since  various  private  and 
government  organizations  are  responsible  for  the  development  and 
operation  of  the  database  software  and  methodology. 
Configuration  management  of  the  centralized  database  would 
therefore  entail  only  configuration  management  of  the  data 
entries  in  the  database.  As  new  capabilities  arise  in  finite 
element  modeling  and  analysis,  it  would  be  possible  to  modify  the 
attibutes  in  the  information  database  to  meet  different  sets  of 
user  needs. 

The  type  and  extent  of  the  data  in  the  information  database 
should  include  both  intrinsic  and  extrinsic  attributes  which  can 
be  used  tc  uniquely  identify  finite  element  models  when  viewed  in 
the  context  of  other  models.  Intrinsic  data  is  that  which  can  be 
obtained  directly  from  examination  of  the  finite  element  model 
bulk  data  deck,  whereas  extrinsic  data  is  that  which  can  be 
obtained  only  from  model  documentation.  Intrinsic  data  can  be 
loaded  in  an  automated  fashion  through  the  input  module  (Figure 
(6-1),  which  would  take  finite  element  models  in  a  standard 
format  (e.g.  COSMIC  NASTRAN,  MSC  NASTRAN,  ANSYS,  etc.)  and 
extract  data  for  deposit  in  the  information  database.  The  input 
module  could  also  be  used  to  automatically  create  a  neutral 
graphics  file  which  can  be  used  to  display  the  finite  element 
model  topology  to  the  user  through  the  user  interface.  To  ensure 


data  integrity,  a  one-to-one  mapping  of  database  operations  would 
be  implemented  for  the  input  of  intrinsic  and  extrinsic  data. 
The  extrinsic  data  would  be  entered  through  the  input  module  by 
the  system  operator  through  standard  forms  in  the  user  interface. 
To  simplify  this  process,  it  is  anticipated  that  database  users 
will  be  required  to  complete  standard  documentation  available  in 
standard  forms.  As  users  gain  familiarity  with  the  centralized 
database,  they  can  input  extrinsic  data  directly  to  the  database 
through  the  user  interface  in  report  writer  format,  subject  to 
approval  by  the  system  operator  for  dissemination  throughout  the 
finite  element  user  community. 

The  model  database  will  contain  finite  element  bulk  data 
stored  off-line  on  tapes  in  a  model  library,  To  ensure  data 
integrity,  models  could  first  be  qualified  by  either  the  database 
user  or  system  operator  before  entry  into  the  model  database. 
The  qualification  process  could  involve  checks  for  element 
conectivity,  coincident  nodes  or  elements,  grounding,  or  other 
standard  validation  procedures.  It  is  anticipated  that  the 
finite  element  models  will  be  stored  by  the  input  module  into  the 
model  database  in  an  industry  standard  relational  format,  such  as 
IGES  (International  Graphics  Exchange  Specification)  or  PDES 
(Product  Data  Exchange  Specification).  The  primary  objective  of 
these  standards  was  to  provide  a  consistent  means  by  which  data 
may  be  exchanged  among  various  software  and  hardware  systems. 
For  finite  element  data,  these  standards  are  fairly  complete, 
containing  a  wide  range  of  data  typos  which  are  currently  used  by 


various  finite  element  codes.  The  use  of  an  existing  industry 


standard  storage  format  for  the  model  database  gives  the 
centralized  database  built-in  versatility  to  a  wide  range  of 
applications  and  maximizes  data  sharability  among  the  user 
community.  On  one  hand,  most  proprietary  finite  element  model 
pre-  and  post-processors  (i.e.  PDA  PATRAN,  SDRC  SUPERTAB,  ANSYS 
PREP-7)  currently  maintain  capabilities  for  reading  and  writing 
finite  element  models  consistent  with  these  specifications. 
Therefore,  the  centralized  database  would  not  necessarily  need 
specialized  software  modules  to  communicate  with  these  codes.  On 
the  other  hand,  if  alternative  finite  element  model  formats  are 
needed,  users  can  create  specialized  software  to  communicate  with 
the  model  database  by  adhering  to  the  published  specification. 
The  centralized  database  could  be  made  even  more  adaptable  to  new 
applications  through  modifications  in  the  database  schema  and/or 
communication  software. 

The  database  controller  and  user  interface  modules  are  the 
primary  means  by  which  users  can  interact  with  the  database.  The 
functions  of  the  database  controller  are  to  ensure  the  proper 
allocation  of  costs  among  database  users,  to  maintain  data 
security,  to  track  user  requests,  and  to  monitor  system 
performance.  The  user  interface  module  will  provide  users  with  a 
set  of  tools  by  which  they  can  have  easy  and  controlled  access  to 
the  database  as  well  as  add  new  applications.  Initially,  users 
should  be  able  to  perform  basic  functions  such  as  querying  sets 
of  models  for  information  and  requesting  the  storage  or  retrieval 
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of  models  to  or  from  the  database  in  various  model  formats. 
These  database  operations  will  be  simplified  by  the  use  of 
standard  forms  and  menus  in  the  user  interface.  In  order  to 
minimize  the  initial  development  and  operation  of  the  centralized 
database,  it  is  recommended  that  the  user  interface  and  database 
controller  utilize  existing  software,  such  as  that  developed  for 
the  Air  Force  for  the  Integrated  Information  Support  System 
(IISS).  The  IISS  user  interface  allows  users  to  access  a  very 
wide  variety  of  applications  on  different  terminals  and  different 
host  computers  in  a  uniform  manner.  The  use  of  such  software  has 
advantages  in  that  new  developments  in  computer  hardware,  such  as 
graphics  devices,  can  be  addressed  by  various  private  and 
government  agencies,  allowing  the  centralized  database  to 
concentrate  on  developments  in  finite  element  analysis. 

The  database  interrogation  process  would  involve  a  menu- 
driven  procedure  in  the  user  interface  to  guide  the  user  in  the 
examination  of  finite  element  models.  The  user  interface  would 
incorporate  standard  forms  to  minimize  user  training  and  re¬ 
learning  of  database  procedures,  and  a  graphics  driver  to 
facilite  the  display  of  finite  element  model  topologies.  The 
database  query  module  (Figure  6-1)  would  utilize  standard  search 
algorithms  provided  by  the  relational  database  management  system. 
The  user  could  therefore  scan  the  entire  information  database  to 
find  models  based  on  a  set  of  product  identification  codes, 
material  properties,  key  words,  applications,  or  any  other 
combination  of  intrinsic  or  extrinsic  attributes  which  describe 


the  model.  As  the  user  narrows  his  search  by  finding  models 
which  appear  to  satisfy  his  needs,  he  would  be  allowed  to  display 
these  models  at  the  terminal,  or  request  delivery  of  the  models 
to  his  location.  As  outlined  above,  only  certain  users  will  have 
access  to  certain  data  in  the  information  database,  subject  to 
approval  by  the  system  operator. 

The  extraction  of  a  model  from  the  centralized  database 
would  first  involve  a  request  from  the  user  to  the  system 
operator.  This  request  can  be  checked  by  the  database  controller 
to  ensure  that  the  user  has  proper  authority  to  obtain  the  model. 
The  user  request  could  contain  delivery  instructions  (e.g.  user 
name,  location,  required  date,  etc.)  and  format  specifications 
(e.g.  storage  media,  model  format,  etc.)  which  would  be  entered 
into  the  database  controller  via  the  menu-driven  user  interface. 
The  location  of  the  model  in  the  model  database  (library)  would 
be  stored  in  the  information  database,  and  the  system  operator 
would  retrieve  and  load  this  tape  onto  the  computer.  The  output 
module  (Figure  6-1)  would  then  process  a  batch  job,  in  which  the 
model  in  the  database  would  be  converted  to  the  proper  format  and 
copied  onto  tape  for  delivery.  Model  documentation,  in  standard 
forms,  would  also  be  extracted  from  the  information  database  for 
delivery  to  the  user.  A  mailing  label  could  be  automatically 
generated  by  the  output  module,  and  the  entire  package,  including 
tape  and  documentation,  would  be  sent  to  the  requesting  user. 

The  database  architecture  suggested  above  is  an  efficient 
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means  by  which  the  database  requirements  in  Section  5  may  be 
satisfied.  It  is  important  to  note  that  the  database 
architecture  can  utilize  existing  computer  hardware  and  software, 
minimizing  development  costs.  Furthermore,  the  modular  design 
allows  for  the  adaptation  of  new  hardware  and  software 
capabilities  as  they  arise.  The  database  architecture 
establishes  the  overall  dataflow  and  user  interaction  with  the 
database.  From  this  architecture,  it  is  necessary  to  derive 
additional  requirements  pertaining  to  the  operation  of  each 
software  module.  No  attempt  is  made  at  deriving  these 
requirements,  since  these  activities  are  ideally  suited  to  the 
initial  development  and  implementation  phases  of  the  database. 


7.  IMPLEMENTATION  OF  CENTRALIZED  DATABASE 


The  implementation  of  the  centralized  finite  element  model 
database  for  use  throughout  the  Air  Force  requires  sound 
judgement  to  reduce  costs  and  possible  technical  risks  to  the 
user  community.  Database  implementation  issues  include  its 
initial  development,  its  adaptation  to  the  user  community,  its 
operation  and  maintenance,  and  associated  costs  in  each  of  these 
areas.  The  careful  planning  of  the  database  implementation  can 
ensure  Che  longevity  of  the  database  and  its  continued 
effectiveness  throughout  its  lifetime. 

The  initial  development  of  the  centralized  database  should 
consider  the  use  of  existing  software  and  standards  and  address 
only  a  limited  set  of  finite  element  modeling  and  analysis 
capabilities.  As  is  often  the  case,  many  database  development 
programs  start  out  with  very  ambitious  goals,  requiring  the 
extensive  development  of  new  technologies  and/or  the  extensive 
modeling  of  a  wide  range  of  data  types.  As  a  result,  development 
costs  may  increase,  and  the  potential  pay-off  and  justification 
for  the  database  may  not  be  immediately  evident.  Furthermore, 
the  rapid  technological  advancements  in  both  computer  hardware 
and  software  applications  may  render  the  centralized  database 
obsolete  when  it  is  finally  introduced  Co  the  user  community. 
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The  centralized  database  must  theiefore  be  evolutionary,  and  be 
adaptable  to  an  ever-changing  set  of  user  requircnents  as  they 
arise.  As  users  gain  familiarity  with  the  database,  new 
capabilities  can  be  introduced  to  Che  database  to  address  their 
specific  needs. 

The  most  important  task  in  the  initial  stages  of  database 
implementation  is  the  determination  of  methods  by  which  finite 
element  data  can  be  efficiently  managed.  Data  management  first 
involves  the  selection  of  the  types  and  forms  of  data  that  will 
most  effectively  support  the  user  community,  and  allow  for  the 
adaptation  of  new  developments.  The  AFWAL  Data  Item  Description 
(DID)  for  aerospace  structures  (Appendix  A)  should  be  used  as  a 
starting  point  for  determining  the  basic  information  requirements 
which  should  be  associated  with  finite  element  data.  From  these 
requirements,  it  is  necessary  to  examine  standardized  methods  for 
representing  the  data  in  Che  database  to  ensure  its  efficient 
access  and  control.  The  Air  Force  IDEF  methodology  should  be 
considered  for  the  development  of  the  information  database,  and 
the  PDFS  specification  should  be  considered  for  direct 
Implementation  in  the  model  database  (Section  6).  The  logical 
data  models  employed  in  the  information  and  model  databases  will 
then  determine  the  required  capabilities  for  the  database 
communication  software  (data  entry,  retrieval,  and 
interrogation).  Finite  element  model  delivery  requirements  and 
specifications  as  defined  in  the  AFWAL  DID  can  then  be  further 
refined  Co  reflect  the  capabilities  and  information  needs  of  Che 
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database . 


The  adaptation  of  the  centralized  database  to  the  user 
community  must  consider  the  specific  procedural  and  technical 
requirements  tor  the  use  and  deliv._ry  of  tinite  element  models 
within  the  respective  organizations.  A  reasonable  means  for 
adapting  the  database  to  these  organizations  must  therefore  be 
implemented  to  ensure  its  smC'-th  transition  to  the  user 
community.  This  implementation  must  include  the  training  of 
users,  the  establishment  of  computer  accounts,  the  development  of 
costing  algorithms,  and  the  addition  of  security  features. 

For  new  aircraft,  implementation  of  the  centralized 
database  can  have  minimum  impact  on  the  management  of  finite 
element  models,  since  organizational  procedures  would  require 
minimum  modification.  A  standard  finite  element  model  delivery 
specification  can  facilitate  the  implementation  of  the 
centralized  database  by  allowing  for  the  easy  entry  of  these  and 
future  models  into  the  database.  The  delivery  of  finite  element 
models  from  contractor  organizations  should  therefore  follow  some 
standard  specification,  such  as  the  AFWAL  DID.  This  DID  can 
eventually  serve  as  a  Contract  Data  Requirements  List  (CDRL)  item 
to  ensure  consistency  of  all  finite  element  data  from  Air  Force 
contractors.  It  is  important  to  note  that  delivery  requirements 
for  finite  element  models  and  documentation  may  initially 
increase  the  cost  of  performing  analysis,  since  contractors  will 
be  forced  to  demonstrate  technical  accuracy  of  these  models.  It 
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is  believed,  however,  that  this  initial  cost  will  be  justified  by 
both  tangible  and  intangible  benefits  of  a  centralized  database 
which  may  be  used  over  the  life  cycle  of  the  aircraft. 

vor  evistinp  aircraft,  the  Air  Force  must  selectively 
decide  on  whether  a  centralized  database  will  have  long  term 
benefit  to  the  program  before  conversion  to  the  database  approach 
is  determined  necessary.  For  older  systems,  a  complete  set  of 
finite  element  data  may  not  exist.  Therefore,  it  may  not  be 
feasible  to  adapt  these  systems  within  a  centralized  database. 
On  other  systems  which  have  extensive  finite  element  data,  the 
costs  for  conversion  to  the  database  approach  may  not  be 
justified  if  the  system  is  near  the  end  of  its  life  cycle,  or  if 
there  is  reduced  demand  that  finite  element  data  for  this  system 
be  transported  among  organizations.  Conversion  to  the  database 
environment  could  entail  the  conversion  of  numerous  finite 
element  models  which  may  be  in  current  use.  These  activities  may 
have  an  initial  negative  impact  on  productivity,  since 
organizations  will  be  required  to  modify  certain  procedures 
during  implementation. 

The  operation  and  maintenance  of  the  centralized  database 
is  determined  largely  by  the  amount  of  data  in  the  database  and 
the  size  of  the  user  community.  The  costs  of  operating  and 
maintaining  the  database  are  associated  with  hardware  (computers, 
peripherals,  communication  devices,  storage  media,  etc.), 
software  (operating  system,  database,  application  and  conversion 


programs,  etc.),  and  personnel  (system  operator,  database 
administrator,  engineers,  programmers,  etc.)  The  database 
hardware  must  have  adequate  capacity  Co  store  large  amounts  of 
information,  and  to  make  this  information  available  to  a  large 
user  community.  The  database  software  must  be  able  to  support  a 
multi-user  environment,  and  have  capabilities  for  expansion  as 
additional  user  needs  arise.  Personnel  must  be  able  to  support 
the  database  user  community  for  normal  activities  (e.g.  user 
requests,  training,  etc.),  and  be  able  to  develop  additional 
capabilities  and  methodologies  to  address  new  technical  advances. 
The  implementation  of  the  database  must  address  operation  and 
maintenance  costs  from  the  outset,  since  these  factors  can  also 
determine  the  effectiveness  of  the  database. 

A  detailed  implementation  plan,  including  specifications 
for  Che  development  of  each  database  module,  a  description  of  the 
database  schema,  computer  software  and  hardware  options, 
personnel  requirements,  and  associated  costs  are  described  in  the 
ensuing  Phase  II  SBIR  proposal  associated  with  this  report. 
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8.  SUMMARY 


The  application  and  utility  of  finite  element  modeling  and 
analysis  by  various  Air  Force  organizations  throughout  the 
aircraft  life  cycle  is  currently  restricted  by  numerous 
organizational  inefficiencies.  These  inefficiencies  are 
associated  with  data  management  in  the  acquisition,  storage, 
utilization,  and  dissemination  of  these  models  and  their  results 
among  Air  Force  organization<"  and  contractors.  This  problem  is 
compounded  by  the  fact  that  the  Air  Force  does  not  require 
aircraft  contractors  to  deliver  finite  element  models  with  the 
aircraft  when  the  aircraft  becomes  operational.  Consequently, 
there  are  no  standard  procedures  or  formats  by  which  finite 
element  models  may  be  obtained  by  various  Air  Force  organizations 
which  need  them  during  various  aircraft  life  cycle  stages.  This 
condition  has  resulted  in  duplication  of  effort,  inappropriate 
analyses,  ralscoraraunicat ion,  and  increased  costs  throughout  the 
aircraft  life  cycle. 

The  possible  applications  of  centralized  database  of  finite 
element  models  which  may  be  accessed  throughout  the  Air  Force 
have  been  reviewed.  These  studies  indicate  that  it  is  feasible 
to  implement  such  a  database  on  the  basis  of  tangible  and 
intangible  benefits  to  the  user  community.  These  benefits 


include  decreased  costs  over  the  aircraft  life  cycle,  increased 
engineering  efficiency  among  the  various  organizations  which  use 
finite  element  data,  better  communication  among  these 
organizations,  higher  quality  models  and  analysis  results,  and  an 
enhancement  of  competition  among  Air  Force  contractor 
organizations.  This  database  will  require  contractors  to  deliver 
finite  element  models  to  the  Air  Force  in  a  standard  format  with 
standard  documentation  during  various  stages  of  aircraft 
development  and/or  operation. 

The  fundamental  requirements  for  a  centralized  database 
were  examined,  and  it  was  determined  that  with  existing 
technology,  such  a  database  can  be  implemented.  A  database 
architecture  was  developed  which  will  allow  users  in  various  Air 
Force  organizations  the  ability  to  deposit,  retrieve,  and 
interrogate  finite  element  data  in  a  secure  environment 
throughout  the  aircraft  life  cycle.  The  key  feature  of  this 
architecture  is  the  utilization  of  a  dual  database  structure  to 
facilitate  model  identification  and  selection,  to  minimize 
computer  system  on-line  resource  requirements,  and  to  maximize 
data  security.  Guidelines  were  developed  for  the  implementation 
of  the  database,  including  its  initial  development,  adaptation  to 
the  user  community,  and  operation  and  maintenance.  These 
guidelines  comprise  an  implementation  plan  to  ensure  the 
longevity  of  the  database  and  its  continued  effectiveness 
throughout  its  lifetime. 
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DATA  ITEM  DESCRIPTION 
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This  report  describes  the  data  elenents  and  the  format  of  the  finite  element  models  of 
aerospace  structures  tc  be  delivered  to  the  Air  Force.  This  data  will  be  used  to  veri.''y  the 
contractors  structural  analysis  and/or  to  determine  the  effects  of  future  mod  1 f 1 ca t ions  (or 
chanies';  to  the  structure  or  its  operational  conditions.  It  should  be  rcted  that  net  all 
the  data  items  will  be  applicable  to  every  system.  The  applicable  items  will  be  identified 
on  a  CTRL  (TT  Form  1*J23). 
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The  finite  element  data  generated  for  verifying  the  structural  design  criteria  cf  an 
aerospace  vehicle  (designed  and  paid  for  by  the  Air  Force)  should  be  be  the  property  cf 
the  Air  Force  and  should  be  delivered  in  a  suitable  and  understandable  form  for  future 
use.  This  data  will  be  extremely  valuable  in  assessing  the  int'^grlty  cf  the  system  after 
modifications,  repairs  and  mainte nance. 
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10.1  General  Repu  1  remen ts .  The  flhlte  element  data  supplied  l.n  respon.se  to  this  CTRL  iter, 
must  accompany  a  problem  narrative.  This  narrative  must  include  the  following  items; 

•  Configuration  version. 

•  Identification  of  the  documents  and/or  drawings  from  which  the  model  was  generated. 
Copies  of  these  documents  must  be  provided  if  they  are  not  available  to  the 
government . 

•  A  key  diagram  showing  the  location  of  the  component  being  modeled  in  relation  to  th“ 
rest  of  the  structure. 

•  A  brief  description  cf  the  physical  phenomena  being  modeled. 

•  A  discussion  on  the  coarseness/fineness  of  the  grid  selected. 

•  A  rational  explanation  for  the  elements  selected  for  the  model. 

•  An  explanation  of  the  boundary  conditions, 

•  Katerlals  -  Identification  of  the  Mil  Standard  from  which  the  mechanical  properties 
were  derived.  Reasons  for  any  deviations  from  the  standard  properties. 

•  A  complete  description  of  the  flight  maneuvers  for  which  the  loading  conditions  are 
attributed . 

•  Planform  used  for  aerodynamic  analyses  showing  all  important  dimensions. 
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•'  2  Analyais  Data  Requlrtmenta.  The  finite  element  analysis  models  are  classified  into 
following  five  categories: 

I.  Static  Analysis  Models 

II.  Dynamic  Analysis  Models 

III.  Aeroelastlc  Analysis  Models 

IV.  Heat  Transfer  Analysis  Models 

V.  Acoustic  Cavity  Analysis  Models 

The  CDRL  will  call  for  the  specific  models  required. 

10.2.1  Static  Analysis  Model  Requirements.  A  static  analysis  basically  requires  a  good 
stiffness  representation.  However,  when  gravity  loading  or  Inertia  relief  conditions  are 
specified,  a  good  mass  representation  is  also  required.  This  mass  representation  must 
include  both  structural  and  nonstructural  mass  distributions.  Tne  finite  element  models  for 
static  analysis  must  consist  of  the  following  items  as  a  minimum. 

I)  Geometry  -  (as  appropriate) 

Grid  Point  Coordinates 
Element  Types 
El e. Tent  Connections 
Coordinate  Systems 

II)  Element  Properties  -  (as  appropriate) 

Thicknesses 
Cross-sectional  Areas 
Moments  o.'"  Inertias 
To-slonal  Constants 
Fiber  Orientations 

Other  properties  as  required  for  special  elements. 

ill)  Material  Properties  -  (as  appropriate) 

Isotropic 

Anisotropic 

Fiber  Reinforced  Composites 
Temperature  Dependent  Properties 
Stress  Dependent  Properties 
Thermal  Properties 
Damping  Properties 

Other  properties  as  required  for  special  problems. 

Iv)  Boundary  Conditions  -  (as  appropriate) 

Single  Point  Constraints 
Multipoint  Constraints 

Partitioning  for  Reduction  or  Substructuring 
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v)  Loading  -  (as  appropriate) 

Static  Loads 
Gravity  Loads 
Thermal  Loads 
Centrifugal  Loads 

Other  loading  conditions  as  required  for  special  simulations. 

For  buckling  or  nonlinear  analysis  additional  information  is  required  on  tne  following 
Items : 


•  How  the  nonlinear  matrices  are  derived. 

•  The  method  of  solution  for  the  nonlinear  problem. 

•  A  description  of  the  method  In  the  case  of  an  eigenvalue  analysis. 

10.2.2  Dynamic  Analysis  Models .  The  dynamic  analysis  models  require  1)  geometry,  il)  ele¬ 
ment  properties,  iii)  material  properties,  and  Iv)  boundary  conditions  as  described  for  the 
static  case.  In  addition  an  accurate  nonstructural  mass  and  da.mping  representanun  is 
required.  Generally  five  types  of  dynamic  analysis  are  contemplated. 

•  Normal  Modes  Analysis  or 

•  Complex  Eigenvalue  Analysis 

•  Frequency  Response  Analysis 

•  Transient  Response  Analysis 

•  Random  Response  Analysis 

In  the  first  two  cases  only  the  method  of  eigenvalue  analysis  and  the  frequency  (modes) 
range  of  interest  need  be  specified.  For  frequency  response  analysis  the  frequencies  of 
Interest  must  be  specified.  For  transient  response  analysis  the  dynamic  load  must  be 
defined  as  a  function  of  time  or  must  be  provided  as  tabular  values.  For  random  response 
analysis  the  statistical  nature  of  the  input  (such  as  PSD,  Auto  Correlation)  and  the 
statistical  quantities  of  the  output  desired  must  be  specified.  In  addition  all  the 
Information  on  dynamic  reduction  and/or  modal  reduction  must  be  specified. 

10.2.3  Aeroelastlc  Models .  An  aeroelastlc  analysis  requires  mathematical  models  of  the 
structure  and  the  aerodynamics.  The  structure  Is  generally  represented  by  finite  element 
models  (FEM).  The  requirements  for  the  structures  models  are  as  specified  under  static  and 
dynamic  analysis.  They  Include  mass,  stiffness  and  damping  representation.  Both  structural 
and  nonstructural  mass  distributions  shall  be  Included  in  the  mass  model.  The  aerodynamic 
models  are  generally  based  on  paneling  or  equivalent  methods.  The  requirements  of  the  aero¬ 
dynamic  models  are  those  of  the  panel  geometry  which  cover  all  the  lifting  surfaces  Includ¬ 
ing  the  control  surfaces,  the  empennage  (horizontal  and  vertical  tails)  and  canard  surfaces. 
The  fuselage  slender  body  and  Interference  panels  shall  be  modeled  to  represent  the  flow- 
field  adequately.  The  altitude  (air  density),  mach  number  and  other  relevant  aerodynamic 
parameters  must  be  specified.  The  details  of  the  aerodynamic  theory  and  the  limits  of  Its 

■'lldlty  must  be  clearly  defined.  In  addition,  data  for  the  force  and  displacement  transform 
tlons  from  the  structural  grid  to  the  aerodynamic  grid  (and  vice  versa)  shall  be  Included 
In  the  aeroelastlc  models.  Two  types  of  aeroelastlc  analysis  are  contemplated.  Both  deal 
with  the  phenomenon  of  aeroelastlc  stability.  The  real  eigenvalue  analysis  Is  the  basis  for 
determining  the  static  aeroelastlc  stability.  There  are  a  number  of  i&ethods  for  determining 
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^  --,3;::'.;  aeroelsstlc  5ta^;lllty  (flutter  analysis),  and  the  details  of  the  method  (references) 
the  necessary  data  shall  be  provided  with  the  models.  Flutter  analysis  Is  generally  an 
Iterative  process  and  can  also  Involve  more  than  one  flutter  mechanism.  There  are  often 
special  techniques  associated  with  the  flutter  analysis,  and  they  can  be  defined  In  terms  of 
the  ranges  of  the  aerodynamic  parameters.  Such  data  shall  be  Included  In  the  aeroelastlc 
models.  In  addition,  provisions  must  be  made  to  Include  the  effects  of  the  rigid  body  modes 
on  the  flutter  model  (body  freedom  flutter).  If  it  is  anticipated  that  these  models  will  be 
used  for  aeroservoelastlc  analysis,  then  the  data  shall  be  provided  for  a  state  space  formu¬ 
lation.  Also  sensor  actuator  locations  and  their  range  of  operation  and/or  limitations 
shall  be  Included  In  the  data.  In  addition,  a  flight  control  system  block  diagram  shall  be 
p-ovlded  with  sufficient  Information  to  define  all  transfer  functions  and  gains  using 
S-domaln  variables  for  analog  systems  or  Z-domaln  variables  for  digital  systems.  The  units 
of  Importani  parameters  shall  be  provided. 

10.2.-  Heat  Trans f er  Analysis  Models .  There  are  three  elements  to  heat  transfer  models: 
the  heat  conducting  medium,  the  boundary  conditions  and  the  heat  sources  and/or  sinks.  The 
data  requirements  of  the  heat  conducting  medium  are  similar  to  those  defined  fc'  static  and 
dynamic, analysis .  For  Instance  the  geometry  definition  includes  the  grid  point  coordinates, 
elemerit  types,  element  connections  and  coordinate  systems.  Elements  can  be  classified  Into 
volume  heat  conduction  and  surface  elements.  The  element  type  designation  for  the  volume 
heat  conduction  element  Is  generally  derived  from  the  degree  of  approximation  of  Its  shape 
functions.  The  surface  elements  are  used  to  model  a  prescribed  heat  flux,  a  convective  flux 
due  to  the  difference  between  the  surface  temperature  and  the  recovery  temperature  or  local 
ambient  temperature,  and  radiation  heat  excna.nge.  Appropriate  material  properties,  single 
point  and  multipoint  boundary  conditions  and  description  of  the  heat  sources  (applied 
forces)  have  a  similar  correspondence  in  the  static  and/or  dynamic  analysis.  The  surface 
it  convection  or  radiation  details  shall  be  provided  (through  surface  elements)  as  appro- 
...late.  The  response  variables  in  heat  transfer  analysis  are  generally  grid  point  tempera¬ 
tures  or  the  temperature  gradients  and  heat  fluxes  within  the  volume  heat  conduction 
elements  and  the  heat  flow  Into  the  surface  elements.  Four  types  of  heat  transfer  analysis 
are  contemplated: 

I)  Linear  Steady-State  Response  Analysis 

II)  Linear  Transient  Response  Analysis 

III)  Nonlinear  Steady-State  Response  Analysis 

iv)  Nonlinear  T  nslent  Response  Analysis 

It  Is  often  necessary  to  adopt  special  techniques  for  obtaining  stable  solutions, 
particularly  in  the  last  two  cases.  The  data  pertaining  to  these  special  techniques  and  the 
limitations  of  the  nonlinear  algorithms  shall  be  fully  identified. 

'C.2.5  Acoustic  Cavity  Analysis  Models .  Basically  there  are  three  elements  In  acoustic 
cavity  analysis  models:  the  acoustic  medium,  the  boundaries,  and  the  sources  of  excitation. 
T~.e  acoustic  medium  model  shall  consist  of  grid  points  and  acoustic  elements  connecting 
these  grid  points.  The  response  variables  are  generally  the  pressure  levels  and  the  gradi¬ 
ents  of  the  pressures  (with  respect  to  the  spatial  variables)  at  the  grid  points.  So  for  a 
general  three  dimensional  acoustic  analysis  there  will  be  four  degrees  of  freedom  per  node 
(corresponding  to  four  response  variables)  In  an  acoustic  medium  model.  The  properties  of 
e  acoustic  medium  can  vary  with  the  temperature  and  pressure  distribution  and  density, 
e  boundaries  of  the  acoustic  model  can  be  solid  walls,  flexible  walls,  openings  In  the 
walls  and  walls  with  acoustic  material  which  can  be  represented  as  a  complex  acoustic 
Impedance.  For  complicated  boundary  conditions  separate  finite  element  models  may  be 
nece.esary  in  order  to  derive  the  boundary  conditions  for  the  acoustic  model.  These  finite 
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ele3ient  models  are  based  on  solid  mechanics  and  their  data  requirements  are  similar  to  those 
crlbed  for  the  static  and  dynamic  analysis  earlier.  The  acoustic  excitation  source  model 
i,.all  have  information  on  the  spatial  distribution  and  the  statistical  properties  (in  terms 
of  the  frequency  content)  of  the  noise.  For  a  deterministic  case,  however,  definition  of 
the  forcing  function  Includes  the  magnitude,  phasing  and  frequency  along  with  the  spatial 
distribution.  The  acoustic  excitation  is  generally  given  as  velocity  or  pressure  applied  to 
the  medium  over  prescribed  surfaces  or  at  grid  points.  If  the  disturbance  is  from  mechani¬ 
cal  sources,  separate  finite  element  models  of  the  sources  shall  be  supplied  as  required. 
These  models  are  also  generally  solid  mechanics  models  and  their  requirements  are  similar  to 
static  and  dynamic  analysis  models.  Generally  three  types  of  acoustic  analysis  are 
contemplated . 

•  Eigenvalue  Analysis 

•  Steady-State  Solution 

•  Nonlinear-Analysis 

In  the  Eigenvalue  analysis  the  acoustic  natural  frequencies  and  mode  shapes  are  determined. 
The  purpose  la  to  compare  the  natural  frequencies  of  the  cavity  with  those  of  the  forcing 
function  and  estimate  the  resonance  effects,  and  to  compare  the  natural  frequencies  to  the 
resonant  frequencies  of  any  structure  which  may  be  placed  in  the  cavity.  This  analysis 
p'-nvldes  useful  information  for  design  changes  in  the  cavity  either  by  altering  the  overall 
dimensions  or  by  introducing  noise  suppression  mechanisms  such  as  baffles  or  by  adding  noise 
suppression  material  to  introduce  acoustic  wall  Impedance.  This  analysis  does  not  require 
explicit  definition  of  the  forcing  function.  The  steady-state  solution  gives  the  response 
'*■  the  cavity  to  a  given  excitation.  This  analysis  can  be  in  the  time  or  frequency  domain. 

nonlinear  analysis  Involves  an  Iterative  solution  when  the  properties  of  either  the 
cavity  or  the  acoustic  medium  vary  significantly  with  the  pressure  levels  and/or 
temperature . 

10.3  Other  Requirements. 

The  input  data  for  all  the  finite  element  models  must  be  provided  in  a  format 
compatible  with  the  latest  government  version  of  NASTRAN  (COSKIC/NASTRAN).  If  the  original 
analysis  was  made  with  another  finite  element  program,  the  data  shall  be  converted  to  the 
COSHIC/NASTRAN  format.  If  NASTRAN  does  not  have  compatible  elements  or  capability,  the 
elements  that  are  most  appropriate  must  be  identified  and  projections  must  be  provided  on 
the  expected  differences. 

In  addition  to  the  input  data  a  summary  of  output  results  (such  as  deflections, 
stresses,  frequencies,  etc.  at  critical  areas)  shall  be  provided  for  future  validation  of 
the  models.  Also  a  brief  description  of  how  these  results  were  used  to  satisfy  a  specific 
design  criteria.  A  set  of  undeformed  and  deformed  plots  of  the  structure  shall  be  provided 
with  all  the  finite  element  models. 
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